Method and system for generating personal/individual health records

ABSTRACT

A system and method for generating and/or updating a personal/individual health record. Inputs of data to the system may come from diverse sources including, but not limited to, patient questionnaires, insurance company (or other payor) claims data, hospitals, clinics and other institutional providers, and individual physicians and physicians&#39; offices.

RELATED APPLICATIONS

This application is a continuation of U.S. Application Ser. No.13/358,914, filed Jan. 26, 2012, entitled Method and System forGenerating Personal/Individual Health Records which is a continuation ofU.S. application Ser. No. 12/762,673, filed Apr. 19, 2010, which is acontinuation of U.S. application Ser. No. 11/928,305, filed Oct. 30,2007, which was a continuation of U.S. application Ser. Nos. 11/495,093,11/495,092, 11/495,135, 11/494,940, and 11/494,933, all filed on Jul.28, 2006. Each of these applications claimed priority to U.S.Provisional Application Ser. No. 60/704,309 filed Aug. 1, 2005, and arecontinuation-in-part applications of U.S. application Ser. No.10/381,158, filed on Mar. 21, 2003, which was the National Stage ofInternational Application No. PCT/US01/42618, filed Oct. 11, 2001, whichclaimed the benefit of Provisional Application No. 60/239,860 filed onOct. 11, 2000. These applications are hereby incorporated by referencein their entireties.

FIELD OF THE INVENTION

This invention relates generally to computer methods and systems and,more particularly, to computer methods and systems for generatingpersonal/individual health records for individuals by accessing andcompiling data from diverse sources. In one embodiment, a system/methodextracts and compiles data from, among other sources, payor claims datato generate a personal/individual health record for an individual.

BACKGROUND AND SUMMARY OF THE INVENTION

There is a substantial distinction between an electronic medical record(“EMR”) and a personal health record (“PHR”), which is also commonlycalled an individual health record (“IHR”). The terms “PHR” and “IHR”are interchangeably used herein.

An EMR is provider-centric while a PHR is patient-centric. An EMR is nota complete health record of a patient, but is limited in scope to aspecific health care provider. Notably, the electronic medical recorddoes not contain any information from any other health care provider whodoes not have access or share the same specific EMR.

Electronic medical records are known. Typically, the EMR is establishedby hospitals or a group of physicians or less commonly by a physician.The EMR details each encounter between the patient and the provider foreach episode of illness treated by the specific provider (hospital,physicians, or other care givers). Although the EMR is the commonlylooked to as the medico legal record of that particular episode ofillness and its management, it does not contain any information from anyother provider who does not have access or share the same specific EMR.

A patient has no control over his/her EMR. For example, patients have nodirect online access to their EMR and cannot make any entries in therecord. Patients have no control over the access to their EMR and anyonewho has access to the EMR of the specific hospital or physician groupcould access their health records. There is no complete global unifiedrecord of a patient in an EMR unless and until the entire healthcare isbeing delivered by the one provider group who is using the specific EMRfor all patient encounters. The EMR system usually is used by a limitednumber of users (providers).

U.S. patents and published patent applications which relate to the topicof electronic medical records include: U.S. Pat. Nos. 5,867,821;6,684,276; 6,775,670; 2004/0078227; and 2004/0172307. This listing ofU.S. patent publications is not offered or intended to be taken asexhaustive, but rather as illustrative of patent filings on this topic.To the extent necessary for a complete understanding of the backgroundrelating to known electronic medical records and related systems, thedisclosures of these publications are hereby expressly incorporated intothis application by this reference thereto.

The present invention is not merely a system for electronically storingand accessing medical records, but relates to computerized systems andmethods, including software attendant thereto, for generating a personalhealth record (“PHR”), also described as an Individual Health Record orElectronic Health Record (hereafter “IHR” or “EHR”). In contrast to anEMR, the PHR contemplated herein is intended to include all relevanthealth-related information for a patient, regardless of the specifichealth care provider. The clinical information regarding the individualpatient may be collected from diverse sources including, but not limitedto information from claims through the health plans, multiple EMR'sbeing used from different providers providing care to that patient,medication records from the pharmacy benefit managers (“PBMs”),information from labs and imaging centers, and direct input by thepatient to provide a unified personal/individual health record. The PHRmay contain health records of millions of patients with online access tothose millions of patients.

In one embodiment, the invention provides a system and method forgenerating a personal/individual health record that is compiled fromdiverse sources, such as patient questionnaires or direct input, healthplans, pharmacy benefits managers (“PBMs”), labs, imaging centers,freestanding outpatient facilities, hospitals and physicians. The datacollected from the diverse sources is organized into an individualhealth record for a patient. The individual health record may beintegrated with SNOMED codes to allow that data to be encoded underspecific medical diagnostic concepts. SNOMED is a division of theCollege of American Pathologists (“CAP”). SNOMED Clinical Terms (“SNOMEDCT”) is a scientifically-validated, clinical health care terminology andinfrastructure. Health data can be captured, shared and aggregated in aconsistent manner by the SNOMED CT terminology. The terminologycurrently contains over 350,000 hierarchically specified health careconcepts, each with unique meanings and logic-based definitions.Additionally, these health care concepts have distinct relationshipsthat support reliability and consistency for data retrieval. As usedherein, the term “universal health care concept codes” means a commonlanguage that enables a consistent way of indexing, storing, retrieving,and aggregating clinical data across specialties and sites of medicalcare. Each “universal health care concept code” is a unique identifierindicative of a node in a hierarchy of health care concepts to whichother types of medical data can be mapped. The term “universal healthcare concept code” is intended to be synonymous with the term “SNOMEDcode.”

In some embodiments, security and medical privacy could be provided suchthat a patient could have the ability to permit the entire individualhealth record to be viewed by designated persons or only permit selectedparts of the record to be viewed by the authorized persons. Thisauthorization is based on the ability of a patient to block anyinformation relating to a protected class (e.g., mental health,reproductive system conditions in a female or STD, etc.) and/orfunctional area (e.g., illness/condition list, procedure list,medication profile, etc.). Any part of the record relating to thatprotected class and/or functional-area could be blocked and continued tobe automatically blocked until a change is made by the patient.

According to another aspect, the invention provides a method forgenerating a personal/individual health record. The method may includethe act of receiving a data element indicative of a health relatedparameter for a patient. The act of determining a SNOMED codecorresponding to the data element may be included in the method. Anentry may be inserted into a personal/individual health recordassociated with the patient based on the determined SNOMED code.

In some illustrative embodiments, the data element may include payorclaims data. For example, the data element may be a health insuranceclaim code. Depending on the exigencies of a particular application, thedata element may include patient questionnaires or direct input, healthplans, pharmacy benefits managers (“PBMs”), labs, imaging centers,freestanding outpatient facilities, hospitals and physicians.Embodiments are also contemplated in which the data element may includean ICD code, a CPT code, a NDC code, LOINC code, or a code from aproprietary coding system, such as Lapcorps' lab and order codes.

The method may include the act of transmitting a description of theentry to a client system in some embodiments. In some cases, a firstdescription and a second description may be associated with the entry.In such embodiments, the first description could be synonymous with thesecond description. For example, the first description may use medicalterminology whereas the second description could use layman's terms.Preferably, the first description is transmitted if the client system isassociated with a healthcare provider whereas the second description istransmitted if the client system is not associated with a health careprovider.

In some illustrative embodiments, the method may include the act ofdetermining whether the individual health record includes any entriesrelated to the new entry. Preferably, any entries in the individualhealth record that are related to the entry are associated based on thedetermined SNOMED code.

According to another aspect, the invention provides a data processingsystem with a messaging facility configured to receive a data elementindicative of a health related parameter for a patient. The system mayinclude a correlation module configured to determine a SNOMED codecorresponding to the data element. A PHR population engine may beoperably associated with the correlation module, such that the PHRpopulation engine is configured to insert health related data associatedwith the SNOMED code into a personal/individual health record associatedwith the patient.

In some embodiments, the system may include an access management moduleconfigured to communicate with a client system. In some cases, theaccess management module could be configured to transmit a descriptionof the health related data to the client system. For example, the PHRpopulation engine may associate more than one synonymous descriptionwith the health related data. Embodiments are contemplated in which someof the descriptions use medical terminology and others use layman'stwins.

The system may include a filtering module in some embodiments.Typically, the filtering module may be configured to determine whetherthe client system is associated with a healthcare provider. Thedescription transmitted to the client system may differ depending onwhether the client system is associated with a healthcare provider. Insome embodiments, the filtering module may be configured to change thedescription of the health related data based on a description of aSNOMED code up a SNOMED hierarchy to adjust the resolution of data.

In some embodiments, the system may include a PHR database configured tostore a plurality of individual health records. The system may alsoinclude a data analysis module configured to identify patterns orrelationships among the plurality of individual health records in thePHR database based on related SNOMED codes. For example, the dataanalysis module may be configured to measure effectiveness of healthcaretreatment based on outcomes associated with the plurality of individualhealth records having related SNOMED codes. In some cases, the dataanalysis module may be configured to perform population studies based onSNOMED codes in the plurality of individual health records.

Embodiments are also contemplated in which the data analysis module maybe configured to analyze a health care provider's quality of care andcost. For example, the data analysis module may profile health careproviders based on patient outcomes associated with the health careproviders. Likewise, the health care providers could be profiled interms of costs, such as the cost charged by health care providers forvarious procedures. Health care providers could thus be ranked based onquality of care and cost. This information could allow various payors,such as insurance companies or governmental entities, to establish alist of preferred health care providers based on a formula that includesobjective measures for quality of care and cost, as well as possiblyother factors.

According to a further aspect, the invention provides a method ofgenerating a personal/individual health record. The method may includethe act of receiving a claims data element indicative of a healthinsurance claim associated with a patient. The SNOMED code correspondingto the claims data element may be determined. The method may alsoinclude inserting the SNOMED code into a personal/individual healthrecord associated with the patient.

In some embodiments, the method may include the act of receiving aquestionnaire data element indicative of an answer to a questionnaire bythe patient. A SNOMED code corresponding to the questionnaire dataelement may be determined and inserted into the individual health recordassociated with the patient. Embodiments are also contemplated in whichthe method includes the act of receiving a clinical data elementindicative of clinical data associated with the patient. In suchembodiments, a SNOMED code corresponding to the clinical data elementmay be determined and inserted into the individual health recordassociated with the patient.

According to another aspect, the invention provides a method forgenerating a personal/individual health record. The method may includethe act of receiving a data element indicative of a health relatedparameter for a patient. A health related concept that corresponds tothe data element may be identified, such that the health related conceptis selected from a hierarchical arrangement of health related concepts.A new entry may be inserting into the individual health care record thatis representative of the identified health related concept. Also, thenew entry may be associated with entries in the individual health recordthat have a hierarchical relationship to the new entry.

In some embodiments, the hierarchical arrangement includes nodesrepresentative of medical diagnoses or medical procedures. For example,the hierarchical arrangement may include at least 300,000 nodes, such asa plurality of SNOMED Clinical Terms.

According to a further aspect, the invention provides acomputer-readable medium having a data structure stored thereon. Thedata structure may include a diagnosis data field for storing aplurality of diagnosis data elements representative of medical diagnosesassociated with a patient. For example, at least one diagnosis dataelement may be derived from a payor diagnosis code based on a SNOMEDcode. A procedure data field for storing a plurality of procedure dataelements representative of medical procedures associated with thepatient may also be included in the data structure. Preferably, at leastone procedure data element is derived from a payor procedure code basedon a SNOMED code. In some cases, the data element may be manuallyentered.

In some embodiments, a diagnosis data element may be derived from an ICDcode. Embodiments are also contemplated in which a procedure dataelement may be derived from a CPT code. Other embodiments arecontemplated in which other health-related information could be derivedfrom other types of codes, such as LOINC codes or proprietary codes,such as Lapcorbs' lab and order codes.

Depending on the particular application, the data structure may includea medication data field for storing a plurality of medication dataelements representative of medications associated with the patient. Forexample, a medication data element may be derived from a healthinsurance medication code based on a SNOMED code. In some cases, amedication data element may be derived from a NDC code. In someembodiments, the procedure data element may be derived from aquestionnaire answered by the patient based on a SNOMED code associatedwith an answer to the questionnaire.

A still further aspect of the invention is achieved by a computer-usablemedium having computer readable instructions stored thereon forexecution by a processor to perform a method. In some cases, the methodincludes the act of receiving a claims data element indicative of ahealth insurance claim associated with a patient. A SNOMED codecorresponding to the claims data element may be determined and insertedinto a personal/individual health record associated with the patient.The method may include the act of receiving a questionnaire data elementindicative of an answer to a questionnaire by the patient. The SNOMEDcode corresponding to the questionnaire data element may be determinedand inserted into the individual health record associated with thepatient. The method may include the act of receiving a clinical dataelement indicative of clinical data associated with the patient. TheSNOMED code corresponding to the clinical data element may be determinedand inserted into the individual health record associated with thepatient.

According to another aspect, the invention provides a method forselectively restricting access to a personal/individual health record.The method may include associating an access list for each user capableof accessing a personal/individual health record associated with apatient, such that the access list categorizes the individual healthrecord into a restricted set of data elements and an accessible set ofdata elements. A request may be received from a user for a data elementin the individual health record. The method may include the act ofdetermining whether the data element is in the restricted set of dataelements by reviewing an access list associated with the user. If thedata element is in the restricted set of data elements, access to thedata element will be denied. However, if the data element is in theaccessible set of data elements, the user will be allowed to access tothe data element. In some embodiments, a predetermined list of possiblerestricted areas may be presented to a patient. The access list may becreated responsive to selections by the patient.

According to a further aspect, the invention provides a method forgenerating a individual health record, in which the desired informationfrom each source is pre-selected so as to collect information which isimportant and necessary for the continuing care of a patient and thusavoid massive accumulation of data in the patient's individual healthrecord, which has none or little relevance to continuing care. Thisallows the user not to spend excessive amounts of time scrolling throughlots of data to find actionable information. For example, a massiveamount of information is typically collected in an EMR following aninpatient admission, such as extensive nursing reports, voluminous labresults, information regarding the scheduling of tests and proceduresduring the hospitalization. In some cases, the information which isimported in the PHR may be less than ten percent of the EMR and includeonly pre-selected types of data, such as the admission history andphysical exam, discharge summary and discharge plans, and surgicalreport and pre-selected test results such as MRI, CT-Scans, andangiography results.

A further aspect of the invention is achieved by a method for generatinga personal/individual health record. The method may include the act ofreceiving payor claims data associated with a patient. Encounter dataindicative of an encounter between the patient and a health careprovider may be derived from the payor claims data. A new entry may beinserted into a personal/individual health record associated with thepatient based on the encounter data. In some embodiments, the derivingstep may include deriving a primary care physician encounter history, anoutpatient encounter history and a hospital admissions history from thepayor claims data.

According to another aspect, the invention provides a method offiltering data in a personal/individual health record. The method mayinclude receiving a request from a health care provider for apersonal/individual health record associated with a patient. A specialtyassociated with the health care provider may be identified. The dataelements in the individual health record that relate to the specialty ofthe health care provider may be determined. In response to the request,the health care provider may be presented with any data elements in theindividual health record that were determined to relate to thespecialty.

Additional features and advantages of this invention will becomeapparent to those skilled in the art upon consideration of the followingdetailed description of the illustrated embodiment exemplifying the bestmode of carrying out the invention as presently perceived.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a diagrammatic representation of a health care data systemaccording to an embodiment of the present invention;

FIG. 2 shows a block diagram of an example PHR system according to anembodiment of the present invention;

FIG. 3 shows an example table using a MPI identifier according to anembodiment of the present invention;

FIGS. 4A-4E show a database diagram illustrative of a portion of oneembodiment of a system and method according to the present invention;

FIG. 5 shows a block diagram of a portion of an embodiment of thepresent invention;

FIG. 6 shows an example window in which access control for theindividual health record may be established;

FIG. 7 shows an example window denying permission to access a portion ofthe individual health record;

FIG. 8 shows an example window in which a user may override arestriction to a personal/individual health record;

FIG. 9 shows an example audit report that may be generated by the systemaccording to an embodiment of the present invention; and

FIG. 10 shows a flow chart which illustrates an embodiment of a systemand method for populating a personal/individual health record with data.

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to variousmodifications and alternative forms, specific exemplary embodimentsthereof have been shown by way of example in the drawings and willherein be described in detail. It should be understood, however, thatthere is no intent to limit the concepts of the present disclosure tothe particular forms disclosed, but on the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the disclosure.

As should be appreciated by one of skill in the art, the presentinvention may be embodied in many different forms, such as one or moredevices, methods, data processing systems or program products.Accordingly, embodiments of the invention may take the form of anentirely software embodiment or an embodiment combining hardware andsoftware aspects. Furthermore, embodiments of the invention may take theform of a computer program product on a computer-readable storage mediumhaving computer-readable program code embodied in the storage medium.Any suitable storage medium may be utilized including read-only memory(“ROM”), RAM, DRAM, SDRAM, hard disks, CD-ROMs, DVD-ROMs, any opticalstorage device, and any magnetic storage device.

FIG. 1 shows a health care data system 100 in accordance with oneillustrative embodiment that may be used to build, access, analyze,and/or update a Personal Health Record, also described as an ElectronicHealth Record or Individual Health Record (hereafter the terms “PHR” and“EHR” and “IHR” are intended to convey the same meaning). As shown, thehealth care data system 100 includes a personal health record system 102(“PHR System”) that is configured to provide access to individual healthrecords via a network 104 to one or more client systems or users 106.The PHR system 102 may take the form of hardware, software, or maycombine aspects of hardware and software. Although the PHR system 102 isrepresented by a single computing device in FIG. 1 for purposes ofexample, the operation of the PHR system 102 may be distributed among aplurality of computing devices. For example, it should be appreciatedthat various subsystems (or portions of subsystems) of the PHR system102 may operate on different computing devices. In some suchembodiments, the various subsystems of the PHR system 102 maycommunicate over the network 104.

The network 104 may be any type of communication scheme that allowscomputing devices to share and/or transfer data. For example, thenetwork 104 may include fiber optic, wired, and/or wirelesscommunication capability in any of a plurality of protocols, such asTCP/IP, Ethernet, WAP, IEEE 802.11, or any other protocol. Embodimentsare contemplated in which the PHR system 102 may be accessible through ashared public infrastructure, such as the Internet. In such embodiments,any data transmitted over the shared public infrastructure is preferablyencrypted, such as by using a public key infrastructure (“PKI”)certificate and/or secure sockets layer (“SSL”). In some exemplaryembodiments, a virtual private network (“VPN”) may be used. Thoseskilled in the art should appreciate that various other securitymeasures could be employed in relation to transmitting data over thenetwork 104.

The client systems (or users) 106 may be any form of computing devicesthat can receive and send digital signals. By way of example, the clientsystems 106 may include personal computers (“PCs”), tablet computers,notebook computers, servers, personal digital assistants (“PDAs”), orcellular phones. The client system 106 shown in FIG. 1 includes labelsindicative of typical users of the PHR system 102. For example,embodiments are contemplated in which patients, hospitals, employers,physicians, billing offices, healthcare providers and/or healthcarepractices may access the PHR system 102. However, the client system'slabels shown in FIG. 1 are provided solely for purposes of example, butare not intended to limit the type of users or require particular usersto connect to the PHR system 10.

FIG. 2 shows an example embodiment of the PHR system 102. In theembodiment shown, the PHR system 102 includes a PHR database 200, a PHRpopulation engine 202, a security module 204, a security database 206, acorrelation module 208, a correlation table 210, a data analysis module212, messaging facility 214, an access management module 216, and afiltering, module 218. Embodiments are also contemplated in which one ormore of these subsystems of the PHR system 102 are optional, but maymerely be “nice to have” depending upon the exigencies of a particularsituation. For example, the data analysis module 212 may be optional insome embodiments. By way of another example, the filtering module 218may be optional in some embodiments. As shown, the PHR system 102 hasaccess to payor claims data 220 and health related data 222. In someembodiments, the payor claims data 220 and the health related data 222may be accessible to the PHR system 102 via the network 104 from theclient systems 106.

The PHR database 200 may be structured to store various data relating tothe health care of patients, including individual health records.Preferably, the PHR database 200 includes a plurality of PHRs for aplurality of patients. Typically, the PHR database 200 may include tenthousand to sixty million or more PHRs. Embodiments are contemplated inwhich the PHR database 200 may be a single database or a plurality ofdatabases, each of which may be of any variety of database formats orlanguages. It should be appreciated that the PHR database 200 may be alogical dataset that may physically reside on a single storage medium ormultiple storage media. In some cases, for example, the PHR database 200may be a logical dataset that physically resides in multiple geographiclocations.

In some embodiments, the PHR database 200 may include a master patientindex (“MPI”) field. The MPI field allows for the assignment of a uniqueidentifier that defines an entity, such as a patient. Due to the massiveamount of PHRs contemplated in the PHR database 200, many of thepatients may have the same name. Consider, for example, a PHR database200 that includes twenty million PHRs. In this example, there may bethousands of patients with the last name of “Smith” and numerous personswith the name “John Smith.” Although the use of the MPI willdifferentiate the persons, the assignment of an MPI to a patient mayinclude other criteria that may be unique to a patient. In someembodiments, for example, various other criteria, other than name, maybe used to determine whether an entity has already been assigned an MPI,before an MPI is assigned. For example, the PHR system 102 may determinewhether various data elements already exist in the PHR database 200before assigning an MPI, including but not limited to tax IDs,birthdates, gender, address, etc. If the entity is determined to alreadyexist, the information is applied to an existing PHR. Otherwise, a newPHR is created and a new MPI is assigned.

The MPI could be used to secure data, store patient specific settings,and/or act as a key when requesting health record data, for example. TheMPI could also create a cross reference to identifiers already beingused across different information systems of various healthorganizations. For example, hospitals, lab systems, provider offices,pharmacy benefits managers, health plans and/or other systems may becross-referenced to the MPI, thereby tying all relevant data to anappropriate patient. By way of another example, the MPI allows a centralpatient search that would allow users to find patients across multiple,massive and discrete health related organizations without requiring anational ID number. In some organizations, for example, there may bedata on fifteen million to twenty million patients. The use of the MPIalso allows data collected from various sources to be aggregated into asingle record {i.e., a single PHR with data collected from a pluralityof sources}.

FIG. 3 is an example use of the MPI with respect to a patient identifiedas “Ann Smith.” In this example, Ms. Smith has been treated by orvisited the six listed healthcare organizations. Each of theseorganizations has assigned their own identifier for Ms. Smith shown bythe system identifier column, while the MPI identifier remains a singleunique tracking mechanism. In some embodiments, the MPI could not onlygenerate a unique identifier for Ms. Smith, but could also crossreference information to the system identifier used by each of theorganizations. In this manner, Ms. Smith's identification could bepicked up when another message from the same system is received. Thisallows the matching of information originating from a wide range ofmedical sources and from multiple payors to a single comprehensivedisplay about a patient. In some embodiments, the MPI could also be usedto tie health information related to a patient and their family members.For example, the presentation of information regarding the patient andtheir family could be available in formats that assist both the healthcare provider and the patient in improving their health care.

FIGS. 4A-4D shows a diagram of an example relational database whichcould be used as the PHR database 200 in some illustrative embodiments.It should be appreciated that the database structure shown in FIG. 4 isfor purposes of example only, but that a multiplicity of databasestructures could be used for the PHR database 200.

The PHR system 102 may include a PHR population engine 202 to populateand/or update the PHRs in the PHR database 200. The PHR populationengine 202 may collect data from a wide variety of sources, such asmedical claims, pharmacy claims, orders and results from laboratorysystems, admission summaries, op report and discharge summaries fromcustom and standard hospital interfaces, and manually enteredinformation from surveys, health risk assessments and direct entry. Insome cases, manually entered data may be inputted by the patientsthemselves or representative from health plans, provider offices,hospitals, etc. By populating the PHRs from a variety of sources, thePHRs would not be limited to the data available from individualpractices and hospitals. The table below shows a variety of sources fromwhich the PHR may be populated, according to one embodiment, along withexample information that may be gleaned from each source:

SOURCE METHOD OF COLLECTION 1. Patients Answers to questionnaires andsurveys. Regular entries pertaining to management of their conditions,such as home blood glucose levels, airway test results, etc., to trackthe progress of the disease condition. Patients may also directly enterinformation, such as over the counter drugs, immunizations andallergies, into their PHR directly by connecting to the PHR system. 2.Health Plans Directly collecting the claims data from the claimprocessing systems on a periodic (e.g., daily basis) or real time basis.Deriving the data to obtain clinical information. This information mayalso be entered directly into PHRs by persons associated with the healthplans, such as case and disease managers. 3. Pharmacy BenefitsElectronic tape or direct access to obtain Manager (“PBM”) data relatingto prescriptions. 4. Labs From the lab systems using Universalinterfaces (e.g. HL7) or customized interfaces. 5. Imaging Centers Fromthe Imaging Center Systems using Universal (HL7) or customizedinterfaces. 6. Freestanding Outpatient From the EMR of the facilityusing Facilities Universal or customized interfaces. 7. HospitalsInformation imported from the respective EMR's of the hospital usingUniversal Interfaces (such ass HL7) or customized interfaces. 8.Physicians a. From the claims submitted to the payers b. direct onlinenotes or input to the PHR

Embodiments are contemplated in which the PHR population engine 202 may“pull” data from various sources. In some embodiments, for example, a“flag” or other notification could be sent to the PHR population engine202 that health related data is ready to be updated. It should also beappreciated that various health related organizations could “push” datato the PHR population engine 202. For example, the client systems 106may access the PHR system 102 to update the PHR of a patient in the PHRdatabase 200. In other embodiments, the PHR population engine 202 mayperiodically receive data from various sources. For example, the PHRpopulation engine 202 may download payor claims data (or other healthrelated information) from an insurance company (or other payor or healthprovider) on a daily, weekly or other periodic basis. Embodiments arecontemplated in which the PHR population engine 202 may download payorclaims data or other health related data on a “real time” basis. Theterm “real time” does not necessarily mean instantaneous, but merelymeans that the PHR population engine 202 would update the PHR database200 with new information before the information would be needed by ahealth care provider. For example, consider a patient that is referredto a specialist based on a visit with his/her primary care physician. Inthis example, the PHR population engine 202 would be considered toupdate the patient's PHR on a “real time” basis if the PHR is updatedwith information from the visit with the primary care physician prior tothe visit with the specialist, whether the appointment with thespecialist is scheduled the same day as the visit to the primary carephysician, the next day, a week later, etc.

In some embodiments, the PHR system 102 may include a messaging facility214 to interact with the PHR population engine 202 in handling messagesthat are received from various sources, such as client systems 106. Insome cases, the messaging facility 214 may also generate responsemessages for client systems 106 that can programmically request anelectronic copy of the PHR. Embodiments are contemplated in whichprogrammical requests for portions of the PHR may be denied based onpermissions associated with the PHR, as described below with respect tothe security module 204.

Preferably, the messaging facility 214 is configured to handle messages20 in a variety of different formats, both standardized formats, andcustom formats. The message formats described herein are provided merelyfor purposes of example; however, it should be appreciated that themessaging facility 214 is not limited to the formats specificallydescribed herein. By way of example, the messaging facility 214 may becapable of handling messages in HL7v2.4 and HL7v2.5 formats. Thesemessage formats include support for various health related information,such as hospital admission and discharge summaries, lab orders,radiology orders, radiology results and lab results. By way of anotherexample, the messaging facility 214 may include support for HL7v3format.

Embodiments are contemplated in which the messaging facility 214includes support for ANSI-X12 837. This message format is defined by theAmerican National Standards committee and imposed by the HealthInsurance Portability and Accountability Act (“HIPAA”) as the currentlyrequired standard for passing health care claims data betweenorganizations. This message format includes a wealth of clinicalinformation, including diagnosis and procedure codes, provider specialtydata, treatment dates and many others.

The messaging facility 214 may also include support for NCPDP 5.1format. This standard for passing prescription and medicationinformation between entities was defined by the National Council forPrescription Drug Programs organization, and has been adopted by HIPAAas a pharmacy batch standard. While this message could be sourced frommany locations, it would most likely be delivered from a PharmacyBenefits Manager (“PBM”). The PBM may be within a health insurance plan,or operate as an individual entity, for example.

In some embodiments, the messaging facility 214 may receive messagesover a secure connection to a web service. In some embodiments, themessaging facility 214 may include a certification mechanism to ensurethat the organization is eligible to submit and request information fromthe PHR system 102. For example, each participating entity may be issueda Public Key Infrastructure (“PKI”) certificate that will allowverification that only authentic messages are passed to the PHR system102. The messages may be sent on a real-time basis from someorganizations, typically hospitals and laboratories, but may be sent ona periodic basis from other organizations, such as health insuranceplans and PBMs.

In some embodiments, the PHR population engine 202 may have access topayor claims data 220. The term “payor claims data” is intended to bebroadly interpreted to include any patient related data associated withthe payment of health related services. Typically, payor claims data 220may be available from (or sent to) payors(s). As used herein, the terms“payor” and “payors” means health insurance plans and/or governmentalbodies that pay for health related services, and/or pharmacy benefitmanagers. For example, the payor claims data 220 may include, but arenot limited to International Classification of Diseases (“ICD”) codes,Current Procedural Terminology (“CPT”) codes, National Drug Code (“NDC”)codes, treating physicians, treatment dates, manually entered data, orother data formats. A wide variety of information may be obtainedthrough the payor claims data 220. An illustrative example ofinformation that could be collected for a PHR from the payor claims data220 is provided below:

General Information

-   -   Age.    -   Sex.

Outpatient Encounter History

-   -   Vaccination history.    -   Mammography in women; retinal examinations for diabetics;        colonoscopy for adults; PSA tests for males; etc.    -   Visits to primary care doctor. Dates, duration, frequency, main        diagnosis at each visit, medication prescribed following each        visit, tests ordered with each visit, changes of medication as a        result of each visit, changes in the frequency of visits to the        PCP, changing diagnoses following visits.    -   Referrals or orders for lab tests and imaging tests with the        diagnosis justifying the tests. Subsequent visit history to        specialists, further tests and admissions to hospitals.    -   Referrals and visits to specialists. Diagnoses by specialists,        lab tests and imaging tests ordered by specialists and diagnoses        justifying tests.    -   Medications prescribed by specialists, with diagnoses. Duration        of medication.    -   Multiple same-condition specialists, or physicians for the same        diagnoses.    -   Medication to medication alerts generated. Medication-clinical        condition adverse reaction alerts generated.    -   Psychotherapy/Psychiatric Therapy—dates, name of caregiver,        diagnoses, medication.

Hospital Outpatient Encounter History

-   -   Tests done at the out patient facility—dates, tests and        diagnoses. Any repeats?    -   Out-patient surgery—date of surgery, type of surgery, diagnoses        for surgery, name of surgeon, name of anesthesiologist,        complications.    -   Hospitalizations following out-patient surgeries.    -   Physical therapy—dates, duration referring physician and        diagnosis.    -   Out-patient or in-patient drug rehabilitation treatment—dates,        treating physicians, diagnoses and follow up visits. Medication        associated or linked with these therapies.    -   Urgent Care/ER Visits—dates, duration, names of physicians,        names of facilities, tests run, and diagnoses.    -   Admissions to hospitals or physician referrals resulting from        urgent care/ER visits. Medications prescribed and procedures        performed.    -   Ambulances/medical transportation—dates, number of times called        in a span of time, diagnoses, treatment rendered by EMT.

Hospital Admissions

-   -   Name of hospital. Date of admission. Date of discharge.        Admitting diagnosis and discharge diagnosis. List of        complications. L.O.S.    -   Problems list. The names/times seen by specialists, their        specialists and diagnoses by them. Time spent by each physician        on every visit. The diagnoses or conditions for which they were        seeing the patient.    -   Tests—lab tests, biopsies, surgical specimen exam, imaging tests        and other tests with the dates and diagnoses and names of        referring physicians and reporting physicians.    -   Treatment days in regular units. Treatment days in intensive        care.    -   Post Hospitalization Management: ECF, NH, physical therapy, at        home nurse visits, and infusion therapy.    -   Medication following discharge.    -   Ongoing complications, if any.    -   Readmission and readmission diagnoses and dates, dates of        admission and discharge, treating physicians and their        specialists and the time they spent with the patients in the        hospital.        It should be appreciated that the above list is provided for        purposes of example only, but that additional information may be        obtained from the payor claims data 220.

It might at first appear implausible that transactional information,such as payor claims data 220, would provide meaningful medical orclinical information for inclusion in a PHR. However, payor claims data220 creates a type of virtual medical record. Every claim which isprocessed typically includes, in addition to various demographicinformation, procedural or visit codes and diagnostic codes. Payorclaims data 220 is generally more comprehensive relating to theencounters between the patients and different as well as diverseproviders than the electronic medical records kept by individualproviders since a health plan (or other payor) will generally receiveclaims from all or most of the significant care providers for anindividual. Using the electronic medical records of the individualproviders to assemble a PHR would, at best, be much more difficult, andwould likely result in a record that is lacking in a full list ofencounters, especially providers whose access was not provided forwhatever reason. Another advantage to using the payor claims data 220 isthat this data is relatively precise and orderly when compared to otherdata sources in the health care industry. The payor claims data 220 alsoprovides a structure which is useful in methodically organizing andpopulating the data, and prioritizing the manner in which extracted datais displayed. In addition, the payor claims data 220 would not needcoordination from the creators/keepers of the data. For example, the useof payor claims data 220 to add information about the hospital admissionof a patient would not need the coordination of the hospital.

Preferably, the payor claims data 220 is “normalized” or placed into astandard format by a separate process. One such process is the Connect™process available from the assignee of the present application. Thisprocess is described in U.S. patent application Ser. No. 10/381,158entitled “System for Communication of Health Care Data” filed on Mar.21, 2003 and claiming the benefit of PCT International Application No.PCT/US01/42618 filed on Oct. 11, 2001. Both U.S. and PCT applicationsare hereby expressly incorporated into this application by thisreference thereto. Although specific to the payor from whom the payorclaims data is obtained, the payor claims data 220 may be more readilyutilized by the remainder of the PHR system 102 than “raw” dataavailable from various health related organizations.

In the embodiment shown, the PHR population engine 202 has access toother health related data 222, which could be used to supplement and/orenhance the payor claims data 220. For example, the health related data222 may be collected from patients using questionnaires. By way ofanother example, the health related data 222 may include clinical dataobtained from various entities, such as hospitals, labs, imagingcenters, or outpatient surgery centers. In addition, the health relatedinformation 40 could be obtained from physicians and/or physicianoffices.

In some embodiments, for example, individuals may be asked to completequestionnaires at the time of enrollment into a health plan, or at somelater time when a PHR is being developed. The following is anillustrative example of information collected for a PHR usingquestionnaires:

General Information

-   -   Race.    -   Weight.    -   Change in Weight.    -   Height.    -   Blood Pressure.    -   History of diabetes, asthma, stroke, heart attack and other        conditions.    -   History of Accident: automobile, motorcycle, bicycle and        work-related.    -   History of potentially dangerous hobbies.    -   Family history of overweight, high blood pressure, diabetes,        heart disease, cancer.    -   Lifestyle factors: smoking, alcohol, drugs, exercise and sports.    -   Visits to various countries where a disease could be contracted.    -   Any other history information that can be obtained by changing        the questions and adding further questions.

Outpatient History

-   -   Vaccination history.    -   Mammography in women; retinal examinations for diabetics        colonoscopy for adults; PSA tests for males; etc.    -   Medications prescribed by specialists, with diagnoses. Duration        of medication.        It should be appreciated that the above list is provided for        purposes of example only, but that additional information may be        obtained from patient questionnaires.

In some embodiments, the health related data 222 may include clinicaldata from hospitals, labs, imaging centers, outpatient surgery centers,and/or similar entities. In some cases, the clinical data may beextracted using a standard format. For example, this information isgenerally available in electronic form in Health Level Seven (“HL7”)format and can be efficiently extracted through the use of interfacesdesigned for compatibility with this format. HL7 is a non-profitvolunteer organization headquartered in Ann Arbor, Mich. that is anAmerican National Standards Institute (“ANSI”)-accredited StandardsDeveloping Organization (“SDO”) operating in the field of healthcare.This organization develops specifications that enable disparatehealthcare applications to exchange key sets of clinical andadministrative data. It should be appreciated that an interface may beprovided to extract data from some other form or format. The followingis an example list of clinical information that may be collected fromthe health related data 222:

-   -   Inpatient admission history and physical examination.    -   Inpatient discharge summary.    -   Selected lab results done during the hospital stay (some of the        test results may be irrelevant for continuing care and may just        add to the clutter).    -   Imaging test results.    -   Pathology reports, including reports of biopsies.    -   Medications administered to the patient.    -   Any other information which is considered relevant for        continuing care.        It should be appreciated that the above list is provided for        purposes of example only, but that additional clinical        information may be obtained from various entities.

The manner in which such clinical information may be accessed willdepend on the state of record keeping in each individual entity. Inhospitals having relatively modern electronic medical record systemsthat use the HL7 format, for example, it should be relatively easy togather the desired clinical information from the electronic medicalrecord (“EMR”) of each patient for each encounter. In hospitals withoutcomprehensive EMR systems, or in those using different data formats, theinformation gathering may still take place, albeit through individuallycrafted interfaces or other means specific to the particular entities ordata types. For example, lab, pathology reports and imaging testsresults could be accessed by building interfaces specific to the systemsused to maintain this data. The fact that many hospitals use outsidevendors for such services, and an individual vendor may serve manyhospitals, will allow an interface to be used across a number ofproviders. Similar solutions could be adopted with other types ofclinical information. Relevant information may also be accessed throughpharmacy systems, such as those maintained by hospitals or thirdparties. Admission history and physical examination and dischargesummaries may also be accessed through transcription centers. Thisapproach may be used with labs, imaging centers, outpatient surgerycenters, and other entities. Many, if not most, of these entities havemodern electronic systems, which are HL7 compatible, facilitating thegathering of relevant information. As discussed above, however, othertechniques could be used to gather the information if not in HL7 format.

The health related data 222 may include information gathered fromphysicians and/or physician offices. There are thousands ofphysician-run clinical software systems in existence, with more varietyand less standardization in record keeping than is the case with theother sources discussed above. One approach to obtaining informationfrom physicians is to recognize what information is not available frompayor claims data, questionnaire data and clinical data, and thenfocusing on obtaining that information. Typically, the information whichthis includes is relatively limited and consists mainly of results ofsome tests done in physician offices. Examples of such tests includeEKG's, cardiac stress tests, echocardiogram tests, EEG's, EMG's, nerveconduction studies, and ultrasound tests done in physician offices. Onepossible approach to facilitate and incentivize physicians to providethis information to assist in building a patient's PHR is to ask orrequire providers to supply the information to a PHR portal. In somecases, for example, the supply of such information could be a conditionfor payment in connection with the subject tests.

In some embodiments, the PHR population engine 202 may interact with thecorrelation module 208 to correlate health related data 222 and/or payorclaims data 220 with a health care concept in an arrangement of healthcare concepts. Preferably, the correlation module 208 encodes the healthrelated data 222 and/or payor claims data 220 into SNOMED (“SystematicNomenclature of Medicine”) codes. The SNOMED codes or health relateddata based on the SNOMED codes may be inserted into the patient's PHR.In some embodiments, other health entries in the PHR relating to theSNOMED code could be associated in the PHR, regardless of the format ormechanism from which the information is derived. By using SNOMED codesin the PHR, differing types of entries, such as illness/conditions,procedures, care plans, biometric trackers, medication profile and labresults, could be tied together for better decision making, dataanalysis, application of permissions and enhanced health tracking.

SNOMED is a division of the College of American Pathologists (“CAP”).SNOMED Clinical Terms (“SNOMED CT”) is a scientifically-validated,clinical health care terminology and infrastructure. Health data can becaptured, shared and aggregated in a consistent manner by the SNOMED CTterminology. The terminology currently contains over 350,000hierarchically specified health care concepts, each with unique meaningsand logic-based definitions. Additionally, these health care conceptshave distinct relationships that support reliability and consistency fordata retrieval. In some embodiments, the correlation module 208 may beassociated with a correlation table 210, which may map health relateddata 222 and/or payor claims data 220 into a health care concept, suchas a SNOMED code.

FIG. 5 provides an example with a PHR for a patient identified as “AnnSmith.” In this example, the PHR includes a MPI field, which containsthe MPI associated with Ann Smith, as discussed above. The example PHRincludes diagnosis, procedure, and medication fields in which the SNOMEDcodes derived from ICD codes, CPT codes and NDC codes, respectively, maybe stored. In the example shown, the payor claims data 220 is the ICD9code of 250.00. The correlation module 208 could correlate this ICD9code into the diabetes concept. The PHR population engine 202 mayinclude the SNOMED code associated with the diabetes concept into thediagnosis field of the PHR for Ann Smith. Other health entries in thePHR relating to diabetes could be associated with this entry in the PHR,regardless of the format or mechanism from which the information isderived, whether from an ICD code, a CPT code, a NDC number or manuallyentered data. Physicians, patients and others could then categorizeinformation related to specific health concepts using the SNOMED codes,including visits, illness/conditions, procedures, immunizations,medications, health action plans, lab results or other related data. Theuse of the MPI field could further enhance the PHR system 102. Since theMPI identifies the patient and the SNOMED code designates the healthconcept, the PHR system 102 may collect and present diverse data in aPHR that can be organized, stored, viewed, and managed by all interestedparties in health care transactions.

The PHR system 102 may include an access management module 216. Theaccess management module may provide an interface to the PHR system 102for client systems 106, to enhance and/or supplement the access providedby the messaging facility 214. In some embodiments, for example, theaccess management module 216 may provide a web-based portal to accessPHRs in the PHR database 200.

In some embodiments, for example, a patient may access his/her PHR viathe web-based portal (or through another connection to the PHR system102). This would allow the patient to supplement his/her PHR withadditional information, such as over the counter medications, allergies,immunizations, etc. The patient could also view his/her PHR using theaccess management module 216. For example, the patient could view adiagnosis, laboratory results and other information in his/her PHR viathe web-based portion (or other connection). In some circumstances, thetiming of patient access to certain records in the PHR may becontrolled. For example, a physician may not want a patient to view thelab results until the physician has reviewed the lab results.Accordingly, in some embodiments, the access management module 216 maybe configured to determine whether records in the PHR have been“released” for patient access. If not, the access management module 216would not allow the patient to view any “unreleased” entries, but onlyallow access to “released” records.

In some embodiments, the access management module 216 may interact witha security module 204 that restricts access to PHRs in the PHR database200. For example, some providers may not be granted access to portionsof the patient's PHR that may be considered sensitive. Whenever a useraccesses a patient's PHR, the security module 204 may evaluate whetherpermission has been granted to that user so that only the informationcontained in the PHR to which that user has been granted permission willbe displayed. The use of the security module 204 in this manner allows apatient to completely control access to his/her PHR. For example, thepatient may specify the default permissions for various types ofentities, including his/her spouse, family members, primary carephysicians, and other health care providers. The term “health careprovider” is intended to be broadly construed to include any persons whoprovide health care as part of their job responsibilities. In someembodiments, the patient may specify the particular individuals to whompermissions may be granted. The use of permissions addresses privacyconcerns of patients, which may allow a higher level of usage, as wellas better care resulting from more patients sharing data electronicallywith their healthcare providers via the PHR.

In some embodiments, portions of the PHRs may be protected by thesecurity module 204 based on the types of health information that apatient may consider sensitive. For example, a patient may elect toallow the designed physician to have full access to their variousillness/condition list, while restricting access to selected diseases,such as sexually transmitted diseases or psychological disorders. If aportion of the PHR relates to an area that may be considered sensitive,the security module 204 may consider that area of the PHR to be aprotected data class. For example, information in a PHR related toreproductive health, mental health, HIV, genetic testing, abortion,sexually transmitted diseases, alcohol abuse, drug abuse, AIDS,contraceptive issues, abuse or neglect, sexual assault and/or othersensitive health issues may be considered protected data classes.Embodiments are contemplated in which a predefined list of sensitivehealth issues could be considered protected data classes. Of course, itshould be appreciated that additional data classes could be added and/ordeleted from the list of protected data classes. In some embodiments,the correlation of payor claims data and/or health related data intoSNOMED codes, as described herein, may be used to categorize the PHRinto protected classes for restricting access to the PHR. For example,each SNOMED code related to HIV could be associated with the HIVprotected class.

Embodiments are also contemplated in which the security module 204 mayrestrict access based on functional areas of a PHR. By way of example,function areas of a PHR may include summary, health risk assessment,health calendar, medical history, medication profile, visit summary,health event record, illness and conditions, my plan for health, accountsummary, benefits and eligibility, change PCP, claims, memberinformation, referrals and authorizations, permissions.

The security module 204 may allow a patient to select entities that mayaccess protected data classes and/or functional areas of his/her PHR.Embodiments are contemplated in which a patient may revoke consent,which would prevent electronic retrieval of his/her PHR. In someembodiments, a patient may restrict access to certain protected dataclasses and/or functional areas. It should be appreciated that therecould be a variety of reasons for a patient to restrict access toprotected data classes and/or functional areas. For example, a patientmay not want clinician specialists to see information not related totheir specialty, or may not want a spouse (or other family member) toview medication information. In some embodiments, the security module204 may provide an error message if access to a restricted area isattempted. In some cases, the protected data classes and/or functionalareas that have been restricted may not be displayed, which wouldprevent an entity being restricted from realizing that a restriction isin place. If a spouse of a patient reviewed his/her PHR, for example,the protected data classes from which the spouse was restricted may notbe visible to the spouse; accordingly, the spouse would not know that arestriction to accessing the PHR was in place.

FIG. 6 shows an example interface that allows a patient to restrictaccess to portions of his/her PHR. In this example, the patient hasselected the access rights for a healthcare provider called “DoctorAllbetter.” As shown, the patient has revoked Doctor Allbetter's accessto all protected data classes, except information related to mentalhealth. In addition, the patient has revoked Dr. Allbetter's access toall functional areas.

In some embodiments, default access rights to a PHR may be established.For example, a payor may define default access rights for each of itsmembers. Embodiments are contemplated in which the default access rightscould be based on various factors, such as relationship, gender, age andlocation of the patient. In this manner, a reasonable level of accessrights based on the patient could be established, even before thepatient customizes the access rights as discussed above.

Embodiments are contemplated in which the security module 204 mayinclude role-based security. In such embodiments, the users may beassigned a role to define the portions of the PHRs to which the user hasaccess. This eliminates the need to establish security access levelsseparately for each user. For example, each role may include a securityprofile defined by the organization that the data that would beaccessed. By way of another example, heath plan data may be protected bythe role that the health plan defines for the user, while the hospitaldata may be protected by a role that the hospital has defined.

In some embodiments, the security module 204 may permit a restriction tobe overridden in certain circumstances. For example, this may allow aphysician to view a restricted portion of a PHR for emergency care. Byallowing some restrictions to be overridden in certain circumstances,this balances privacy concerns with the possible need for emergency carewhere PHR data is required due to the state of the patient.

As shown in FIG. 7, for example, a user may be presented with a windowshowing that permission has not been granted to the portion of the PHRfor which access is sought, but that the restriction may be overridden.In this example, the word “here” in the window is a hyperlink thatallows the user to override the restriction. It should be appreciatedthat FIG. 7 is provided for purposes of example, but that numerousdifferent types of user interfaces could be used to allow a restrictionto be overridden.

In some embodiments, the user may be required to provide a reason foroverriding a restriction. For example, as shown in the illustrativeembodiment in FIG. 8, the user may be allowed to select from a list ofpossible reasons for overriding the restriction and/or manually enter areason. This reason, along with other information regarding theoverride, may be stored by the security module 204, as described hereinwith respect to auditing of the PHR.

The security module 204 may create an audit trail regarding access to apatient's PHR. For example, the audit may include when permission wasgranted, who was granted permission, who recorded the granting of thepermission and what permissions were granted. In some embodiments, thesecurity module 204 may audit whenever a user accesses a patient's PHR.For example, the audit may include when a patient's PHR is accessed, whoaccessed a patient's PHR and what portions of the PHR were accessed. Insome embodiments, the audit and permission data may be stored in thesecurity database 206 and/or in the PHR database and/or other storagelocation.

FIG. 9 shows an example audit report based on information gathered bythe security module 204. In this example report, the user “DoctorAllbetter” has accessed the PHR of a patient called “Ann Smith” on fouroccasions. Each time that Doctor Allbetter accessed Ann Smith's PHR, theaudit report notes the date and time that the PHR was accessed. Forinformation in the PHR to which Doctor Allbetter had access, the examplereport includes a “permission type” column and a column with the reasonfor accessing the PHR. In this example, the first time Doctor Allbetteraccessed the PHR, he/she had consent to access that portion of the PHR.In each of the other three occasions, Doctor Allbetter overrode thepermissions to access a functional area (shown as “FA”) and a protecteddata class (shown as “PDC”) as part of emergency care.

In some embodiments, the PHR system 102 may include a data analysismodule 212. The data analysis module 212 could be configured to identifypatterns or relationships in data contained in the PHR database 200 fora single patient or across multiple patients. For example, the dataanalysis module 212 could perform population studies across manyhealthcare events, such as condition, progress of condition, impact ofco-morbidities on the underlying condition, procedures and medications.Due to the plurality of PHRs in the PHR database 200, the data analysismodule could analyze data relating to a large number of patients. Thedata analysis module 212 could provide an outcomes measurement. Forexample, the data analysis module 212 could identify the medicationsthat were the most successful in controlling diabetes. By way of anotherexample, the data analysis module 212 could compare the results ofsurgery versus medical treatment. By way of another example, the dataanalysis module 212 could analyze surveys in the PHR database 200regarding the effectiveness of treatments, drugs, etc.

In embodiments in which SNOMED encoding is used, as described herein,the data analysis module 212 could use SNOMED codes as a mechanism totie events together, to identify patterns or relationships. For example,the use of SNOMED codes in the PHR database 200 aids in outcomesmeasurements because healthcare events, such as conditions, procedures,medications, and survey information, could be tied to related SNOMEDcodes. By way of example, survey results covering the effectiveness ofchiropractic care for back pain could be measured, as well as theeffectiveness of wellness programs. The use of an MPI could also aid indata analysis. For example, the use of an MPI ensures that all episodesof care, as well as each clinical event from the various data sources,are collected and appropriately stored with the correct patient. Bycollecting all relevant healthcare information for a patient, dataanalysis is greatly enhanced as compared to traditional approaches. Mostpertinent is the ability to compare data from different events that mayhave come from different sources. For example, the data analysis module212 could determine how many patients that on taking a particularmedication are subsequently treated for a particular condition, forexample. By way of another example, the data analysis module 212 couldanalyze how many patients that have had a given surgical procedure hadbeen given a follow-up laboratory procedure.

In some embodiments, the PHR system 102 may include a filtering module218. The filtering module 218 may be configured to change modes to varythe resolution of data that is viewed by a user. By “resolution” it ismeant that the filtering module 218 may filter the patient data toprovide either a higher level view or a lower level view of data in aPHR. For example, consider data in a PHR related to an optic condition.If the filtering module 218 were configured to provide a higher levelview, the optic condition may be described merely as “an opticcondition.” If the filtering module 218 were configured to provide alower level view, the optic condition may be described as a“staphylococcal eye infection.”

In some embodiments, the filtering module 218 may be configured totraverse up and down the SNOMED hierarchy to adjust the resolution ofdata that is viewed by the user. For example, if the filtering module218 were configured for the lowest level view, the user may view adescription associated with the SNOMED code. If the filtering module 218were configured for a higher level view, the user may view a descriptionassociated with a more generalized code related to the SNOMED codestored in the patient's PHR. For example, if the filtering module 218were configured for a high level view, and the SNOMED concept related tothe SNOMED code in the PHR were “kidney disease,” the user may view themore generalized SNOMED concept described as “disorder of the urinarysystem.”

In some embodiments, the filtering module 218 may be configured tofilter patient data based on the type of user accessing the information.For example, the filtering module 218 may filter patient data unrelatedto the specialty of the physician accessing the PHR database 200. Insuch an embodiment, physicians may be associated with a specialty code,such as an X12 code, based on the specialty of the physician. Across-reference table (or other lookup function) may be provided todetermine the relevant SNOMED codes based on the specialty code of thephysician accessing the patient data. In this manner, the physician willnot be overloaded with voluminous patient data, but will be presentedwith patient data relevant to his/her specialty. Of course, thephysician may instruct the filtering module 218 to reveal additionalpatient data that may not be associated with his/her specialty.

Embodiments are contemplated in which various synonyms may be associatedwith each medical concept in the PHR. For example, each PHR in the PHRdatabase 200 may include synonyms or synonymous descriptions for one ormore entries in the PHR that describe the same medical concept, such asa condition, procedure, etc., using varying terminology. The filteringmodule 218 may display the synonym that is best suited to the type ofuser accessing the PHR. Embodiments are contemplated in which certaindescriptions may use medical terminology while another description mayuse layman's terms. For example, a patient accessing his/her PHR mayview an entry as “Heart Attack” while a healthcare provider accessingthe same entry may view “myocardial infarction.” This allows patients toview the PHR using consumer friendly terms whereas health careproviders, such as physicians and nurses, can view detailed medicalterms.

FIG. 10 is a diagram showing acts that may be performed by the PHRSystem 102. In some embodiments, the PHR system 102 may access or beprovided with payor claims data 220. In some embodiments, the payorclaims data 220 could be comprehensively coded using the SNOMED codes.Using the payor claims data 220, the PHR system 102 may determine, for aselected individual and PHR, the diagnosis code associated with aparticular claim. For example, the ICD 9 (“International Classificationof Diseases, 91h Revision”) code may be determined. This operation isrepresented by process block 1004. Following this step, the PHR system102 may retrieve the SNOMED code associated with the diagnosis code.This operation is represented by process block 1006.

Next, as illustrated by process block 1008, a health issue recordassociated with the SNOMED code may be retrieved. The PHR system 102 maythen determine, in decision operation 1010, whether the subjectinformation is already described in an existing user record. If so, thePHR system 102 updates the data, as shown in operation 1012. If not, thePHR system 102 adds this information to the user's PHR, as illustratedby process block 1014. If not, the PHR system 102 populates the user'srecord with the identified health issue.

In addition to handling diagnosis codes, such as ICD 9 codes, the PHRsystem may also determine procedure codes, such as CPT (“CurrentProcedural Terminology”) codes, from each unique claim present in thepayor claims data 220. (Process Block 1016). As illustrated by processblock 1018, the PHR system 102 may retrieve the SNOMED code associatedwith the subject procedure coded (e.g., CPT code). Following this step,a health action record associated with the subject SNOMED code may beretrieved, as illustrated by process block 1020. The PHR system 102 maythen determine, in decision operation 1022, whether the user has thishealth action as an existing entry. If so, the PHR system 102 updatesthe data in process block 1024. If not, the PHR system 102 adds thisinformation to the user's PHR, as illustrated by process block 1026.

In some embodiments, the PHR system 102 may be configured to populate aPHR with prescription related info illation in the payor claims data220. Process block 1028 represents the operation of determining the NDC(“National Drug Code”) number and prescription number for medicationsidentified in the payor claims data. After this information isidentified, the PHR system 102 determines, in decision operation 1030,whether the user has this medication or prescription as an existingentry associated with this provider. If yes, refill information isupdated, as indicated by process block 1032, as necessary. If no, thePHR system 102 recognizes this information as being new information andadds it to the medication profile in the PHR of the subject user, asindicated by processor block 1034.

In some embodiments, the PHR system 102 may be configured to populateand/or update a PHR using health-related data 222 from an entity (e.g.,payor or laboratory organization) other than payor claims data 220.Process block 1038 represents the operation of determining the lab orderand/or result code from the health related data 222. As illustrated byprocess block 1040, the PHR system 102 may retrieve the SNOMED code(s)associated with the code(s). Following this step, a health action recordassociated with the subject SNOMED code(s) may be retrieved, asillustrated by process block 1042. The PHR system 102 may thendetermine, in decision operation 1022, whether the user has this healthaction as an existing entry. If so, the PHR system 102 updates the datain process block 1024. If not, the PHR system 102 adds this informationto the user's PHR, as illustrated by process block 1026. In someembodiments, the data from which the SNOMED code is derived (e.g., ICD 9code, CPT code, NDC code, lab order and/or result code, directly entereddata) may be captured for auditing purposes, as this would provide anexplanation of the information from which the SNOMED was derived. Itshould be appreciated that information, other than a SNOMED code, couldbe derived from the data received from the PHR system 102. For example,the location, type of service, service dates, servicing provider,requesting provided, could also be derived from the payor claims dataand/or health related data received from the PHR system 102.

Process block 1044 represents an operation whereby the user can enterinformation into his or her PHR. This information is preferably enteredvia an interface that guides the user through the addition of healthrecord entries in such a manner as to capture and classify theappropriate SNOMED code, such as the Connect™ application marketed bythe assignee of the present application. Following the entry of thisinformation by the user, the PHR system 102 inserts a correspondinghealth issue or action into the user's PHR, as illustrated by processblock 1046.

Similarly, a health care provider (or other entity) may enterinformation into the PHR of a selected user, as indicated by processblock 1048. This information is also preferably entered via an interfacelike the Connect™ software. Following entry, a health issue or action isinserted into the provider's PHR, as illustrated by process operation1050.

Following entry of all health issues or actions by the PHR system 102,as discussed above, the subject issues and actions are stored andtracked in the PHR database 200. One such data base is provided as partof the Connect™ application referenced above. An application-specificidentifier may be assigned to each member by the Connect™ software.

Process block 1052 illustrates the processing of an access request by amember or user (i.e., one of the individuals for whom a PHR is storedand maintained by the PHR system). A properly logged on and identifieduser can access the information stored in a PHR stored in PHR database200. As discussed herein, the PHR system 102 may verify permission ofthe user as to the requested portion of the PHR, as indicated by processblock 1054 and the security database 206. The subject information can bedisplayed in a variety of formats and using a variety of display totechnologies, as illustrated by block 1056.

Although the present disclosure has been described with reference toparticular means, materials and embodiments, from the foregoingdescription, one skilled in the art can easily ascertain the essentialcharacteristics of the invention and various changes and modificationsmay be made to adapt the various uses and characteristics withoutdeparting from the spirit and scope of the invention.

1. An electronic health record system server for use with analyzingelectronic health records of a plurality of patients enrolled in ahealth plan of a payor, wherein the patients undergo encounters with aplurality of health care providers regarding a health related issue ofthe patients, wherein under the health plan the health care providersrequest payment for at least a portion of the cost for the encountersfrom the payor, wherein the health plan requires the health careproviders to submit health related information of the patients to thepayor to support the cost of encounters with the patient, the electronichealth record system server comprising: a memory for storinginstructions and data associated with electronic health records of aplurality of patients; and a processor configured to execute theinstructions, wherein the instructions cause the processor to performthe steps comprising: (a) transferring payor claims data regarding theplurality of patients to the electronic health record system server; (b)analyzing said payor claims data concerning a respective patient of theplurality of patients to determine which portion of the payor claimsdata is encounter data comprising one or more of a diagnosis of therespective patient, a treatment of the respective patient, a medicationof the respective patient, a procedure of the respective patient, ahistory of office visits of the respective patient with one or more ofthe health care providers, or a duration of office visits of therespective patient; (c) populating the electronic health recordsconcerning the plurality of patients by storing one or more entries intothe electronic health record of the respective patient based on theencounter data, wherein population of at least a portion of the entriesin the electronic health records of the plurality of patients isencounter data extracted from the payor claims data; (d) organizing theelectronic health records by associating together one or more entries inthe respective patient's electronic health record that are related; and(e) analyzing the electronic health records by measuring the outcomes ofspecific treatments of diseases under investigation and providing adirect comparison of outcomes measured of a specific treatment withvarious other treatments to allow setting up or modification of clinicalprotocols.
 2. An electronic health record system server for use withanalyzing electronic health records of a plurality of patients enrolledin a health plan of a payor, wherein the patients undergo encounterswith a plurality of health care providers regarding a health relatedissue of the patients, wherein under the health plan the health careproviders request payment for at least a portion of the cost for theencounters from the payor, wherein the health plan requires the healthcare providers to submit health related information of the patients tothe payor to support the cost of encounters with the patient, theelectronic health record system server comprising: a memory for storinginstructions and data associated with electronic health records of aplurality of patients; and a processor configured to execute theinstructions, wherein the instructions cause the processor to performthe steps comprising: (a) transferring payor claims data regarding theplurality of patients to the electronic health record system server; (b)analyzing said payor claims data concerning a respective patient of theplurality of patients to determine which portion of the payor claimsdata is encounter data comprising one or more of a diagnosis of therespective patient, a treatment of the respective patient, a medicationof the respective patient, a procedure of the respective patient, ahistory of office visits of the respective patient with one or more ofthe health care providers, or a duration of office visits of therespective patient; (c) populating the electronic health recordsconcerning the plurality of patients by storing one or more entries intothe electronic health record of the respective patient based on theencounter data, wherein population of at least a portion of the entriesin the electronic health records of the plurality of patients isencounter data extracted from the payor claims data; (d) organizing theelectronic health records by associating together one or more entries inthe respective patient's electronic health record that are related; and(e) analyzing the electronic health records across multiple patients ofthe plurality of patients to perform a population study concerning ahealth event of interest by identifying patterns in the electronichealth records of the patients concerning the health care event ofinterest.
 3. The system of claim 2, wherein the population study is ananalysis of at least one health event of interest that results in anoutcomes measurement concerning the health event of interest.
 4. Thesystem of claim 3, wherein the outcomes measurement identifies one ormore medications that are most successful in treating the health eventof interest.
 5. The system of claim 3, wherein the outcomes measurementidentifies whether surgery versus medical treatment is most successfulin treating the health event of interest.
 6. The system of claim 3,wherein the outcomes measurement determines an effectiveness of awellness program.
 7. A computerized method for analyzing a plurality ofelectronic health care records, the method comprising the steps of: (a)transferring payor claims data regarding a plurality of patients to anelectronic health record system server; (b) analyzing the payor claimsdata concerning a respective patient of the plurality of patients todetermine which portion of the payor claims data is encounter datacomprising one or more of a diagnosis of the respective patient, atreatment of the respective patient, a medication of the respectivepatient, a procedure of the respective patient, a history of officevisits of the respective patient with one or more of the health careproviders, or a duration of office visits of the respective patient; (c)populating electronic health records concerning the plurality ofpatients by storing one or more entries into an electronic health recordof a respective patient based on the encounter data, wherein populationof at least a portion of the entries in the electronic health records ofthe plurality of patients is encounter data extracted from the payorclaims data; (d) organizing the electronic health records by associatingtogether one or more entries in the respective patient's electronichealth record that are related; and (e) analyzing the electronic healthrecords by measuring the outcomes of specific treatments of diseasesunder investigation and providing a direct comparison of outcomesmeasured of a specific treatment with various other treatments.
 8. Anelectronic health record system server for use with analyzing electronichealth records of a plurality of patients enrolled in a health plan of apayor, wherein the patients undergo encounters with a plurality ofhealth care providers regarding a health related issue of the patients,wherein under the health plan the health care providers request paymentfor at least a portion of the cost for the encounters from the payor,wherein the health plan requires the health care providers to submithealth related information of the patients to the payor to support thecost of encounters with the patient, the electronic health record systemserver comprising: a memory for storing instructions and data associatedwith electronic health records of a plurality of patients; and aprocessor configured to execute the instructions, wherein theinstructions cause the processor to perform the steps comprising: (a)transferring payor data regarding the plurality of patients to theelectronic health record system server; (b) analyzing said payor dataconcerning a respective patient of the plurality of patients todetermine which portion of the payor data is encounter data comprisingone or more of a diagnosis of the respective patient, a treatment of therespective patient, a medication of the respective patient, a procedureof the respective patient, a history of office visits of the respectivepatient with one or more of the health care providers, or a duration ofoffice visits of the respective patient; (c) populating the electronichealth records concerning the plurality of patients by storing one ormore entries into the electronic health record of the respective patientbased on the encounter data, wherein population of at least a portion ofthe entries in the electronic health records of the plurality ofpatients is encounter data extracted from the payor data; (d) organizingthe electronic health records by associating together one or moreentries in the respective patient's electronic health record that arerelated; and (e) analyzing the electronic health records by measuringthe outcomes of specific treatments of diseases under investigation andproviding a direct comparison of outcomes measured of a specifictreatment with various other treatments to allow setting up ormodification of clinical protocols.